385 - raw() and addr() Output Script Descriptors
BIP: 385 source Layer: Applications Title: raw() and addr() Output Script Descriptors Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0385 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationraw()addr()Test VectorsBackwards CompatibilityReference Implementation Abstract This document specifies raw() and addr() output script descriptors. raw() encapsulates a raw script as a descriptor. addr() encapsulates an address as a descriptor. Copyright This BIP is licensed under the BSD 2-clause license. Motivation In order to make descriptors maximally compatible with scripts in use today, it is useful to be able to wrap any arbitrary output script or an address into a descriptor. Specification Two new script expressions are defined: raw() and addr(). raw() The raw(HEX) expression can only be used as ...
384 - combo() Output Script Descriptors
BIP: 384 source Layer: Applications Title: combo() Output Script Descriptors Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0384 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationTest VectorsBackwards CompatibilityReference Implementation Abstract This document specifies combo() output script descriptors. These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output scripts if applicable to the key. Copyright This BIP is licensed under the BSD 2-clause license. Motivation In order to make the transition from traditional key based wallets to descriptor based wallets easier, it is useful to be able to take a key and produce the scripts which have traditionally been produced by wallet software. Specification A new top level script expression is defined: combo(KEY). This expression ...
382 - Segwit Output Script Descriptors
BIP: 382 source Layer: Applications Title: Segwit Output Script Descriptors Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0382 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationwpkh()wsh()Test VectorsBackwards CompatibilityReference Implementation Abstract This document specifies wpkh(), and wsh() output script descriptors. wpkh() descriptors take a key and produces a P2WPKH output script. wsh() descriptors take a script and produces a P2WSH output script. Copyright This BIP is licensed under the BSD 2-clause license. Motivation Segregated Witness added 2 additional standard output script formats: P2WPKH and P2WSH. These expressions allow specifying those formats as a descriptor. Specification Two new script expressions are defined: wpkh(), and wsh(). wpkh() The wpkh(KEY) expression can ...
381 - Non-Segwit Output Script Descriptors
BIP: 381 source Layer: Applications Title: Non-Segwit Output Script Descriptors Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0381 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationpk()pkh()sh()Test VectorsBackwards CompatibilityReference Implementation Abstract This document specifies pk(), pkh(), and sh() output script descriptors. pk() descriptors take a key and produces a P2PK output script. pkh() descriptors take a key and produces a P2PKH output script. sh() descriptors take a script and produces a P2SH output script. Copyright This BIP is licensed under the BSD 2-clause license. Motivation Prior to the activation of Segregated Witness, there were 3 main standard output script formats: P2PK, P2PKH, and P2SH. These expressions allow specifying those formats as a descriptor. Specificat...
383 - Multisig Output Script Descriptors
BIP: 383 source Layer: Applications Title: Multisig Output Script Descriptors Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0383 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationsortedmulti()Multiple Extended KeysTest VectorsBackwards CompatibilityReference Implementation Abstract This document specifies multi(), and sortedmulti() output script descriptors. Both functions take a threshold and one or more public keys and produce a multisig output script. multi() specifies the public keys in the output script in the order given in the descriptor while sortedmulti() sorts the public keys lexicographically when the output script is produced. Copyright This BIP is licensed under the BSD 2-clause license. Motivation The most common complex script used in Bitcoin is a threshold multisig. These e...
386 - tr() Output Script Descriptors
BIP: 386 source Layer: Applications Title: tr() Output Script Descriptors Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0386 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationTree Expressiontr()Modified Key ExpressionTest VectorsBackwards CompatibilityReference Implementation Abstract This document specifies tr() output script descriptors. tr() descriptors take a key and optionally a tree of scripts and produces a P2TR output script. Copyright This BIP is licensed under the BSD 2-clause license. Motivation Taproot added one additional standard output script format: P2TR. These expressions allow specifying those formats as a descriptor. Specification A new script expression is defined: tr(). A new expression is defined: Tree Expressions Tree Expression A Tree Expression (denoted TREE) is ...
30 - Duplicate transactions
BIP: 30 source Layer: Consensus (soft fork) Title: Duplicate transactions Author: Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0030 Status: Final Type: Standards Track Created: 2012-02-22 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationRationaleBackward compatibilityImplementationAcknowledgements Abstract This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them. Copyright This BIP is licensed under the 2-clause BSD license. Motivation So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that e...
42 - A finite monetary supply for Bitcoin
BIP: 42 source Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Final Type: Standards Track Created: 2014-04-01 License: PD Table of ContentsAbstractDetailsOther solutionsFloating-point approximationTruncationProposalImplementationCompatibilityAcknowledgementsCopyright Abstract Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion bitcoin, which symbol color to use for it, and when wallet ...
144 - Segregated Witness (Peer Services)
BIP: 144 source Layer: Peer Services Title: Segregated Witness (Peer Services) Author: Eric Lombrozo Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0144 Status: Final Type: Standards Track Created: 2016-01-08 License: PD Table of ContentsAbstractMotivationSpecificationSerializationHandshakeHashesRelayCreditsReference ImplementationCopyright Abstract This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. Motivation In addition to defining witness structures and requiring commitments in future blocks (BIP141 - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes. Specification Serialization A new serialization format for tx messa...
103 - Block size following technological growth
BIP: 103 source Layer: Consensus (hard fork) Title: Block size following technological growth Author: Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0103 Status: Withdrawn Type: Standards Track Created: 2015-07-21 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationRationaleCompatibilityAcknowledgements Abstract This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. Copyright This BIP is licensed under the 2-clause BSD license. Motivation Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depen...
146 - Dealing with signature encoding malleability
BIP: 146 source Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability Author: Johnson Lau Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0146 Status: Withdrawn Type: Standards Track Created: 2016-08-16 License: PD Table of ContentsAbstractMotivationSpecificationLOW_SNULLFAILExamplesDeploymentCompatibilityImplementationFootnotesAcknowledgementsCopyright Abstract This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding. Motivation Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witne...
66 - Strict DER signatures
BIP: 66 source Layer: Consensus (soft fork) Title: Strict DER signatures Author: Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0066 Status: Final Type: Standards Track Created: 2015-01-10 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationDER encoding referenceExamplesDeploymentCompatibilityImplementationAcknowledgementsDisclosures Abstract This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding. Copyright This BIP is licensed under the 2-clause BSD license. Motivation Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have...
380 - Output Script Descriptors General Operation
BIP: 380 source Layer: Applications Title: Output Script Descriptors General Operation Author: Pieter Wuille Ava Chow Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0380 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationScript ExpressionsKey ExpressionsNormalization of Key Expressions with Hardened DerivationCharacter SetChecksumTest VectorsBackwards CompatibilityReference ImplementationAppendix A: Index of ExpressionsAppendix B: Index of Script Expressions Abstract Output Script Descriptors are a simple language which can be used to describe collections of output scripts. There can be many different descriptor fragments and functions. This document describes the general syntax for descriptors, descriptor checksums, and common expressions. Copyright This BIP is licensed under the BSD 2-clause license. Motivation Bitcoin ...
9 - Version bits with timeout and delay
BIP: 9 source Title: Version bits with timeout and delay Author: Pieter Wuille Peter Todd Greg Maxwell Rusty Russell Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009 Status: Final Type: Informational Created: 2015-10-04 License: PD Table of ContentsAbstractMotivationSpecificationSelection guidelinesStatesBit flagsNew consensus rulesState transitionsWarning mechanismgetblocktemplate changesSupport for future changesRationaleDeploymentsCopyright Abstract This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pau...
62 - Dealing with malleability
NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment. BIP: 62 source Layer: Consensus (soft fork) Title: Dealing with malleability Author: Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0062 Status: Withdrawn Type: Standards Track Created: 2014-03-12 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationNew rulesBlock validityReferencesLow S values in signaturesDER encodingPush operatorsNumbersCompatibility Abstract This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it). Copyright This BIP is licensed under the 2-clause BSD license. Motivation As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, w...
173 - Base32 address format for native v0-16 witness outputs
BIP: 173 source Layer: Applications Title: Base32 address format for native v0-16 witness outputs Author: Pieter Wuille Greg Maxwell Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173 Status: Final Type: Informational Created: 2017-03-20 License: BSD-2-Clause Replaces: 142 Superseded-By: 350 Table of ContentsIntroductionAbstractCopyrightMotivationExamplesSpecificationBech32Segwit address formatCompatibilityRationaleReference implementationsRegistered Human-readable PrefixesAppendicesTest vectorsChecksum designAcknowledgementsDisclosures (added 2024) Introduction Abstract This document proposes a checksummed base32 format, "Bech32", and a standard for native segregated witness output addresses using it. Copyright This BIP is licensed under the 2-clause BSD license. Motivation For most of its history, Bitcoin has relied on base58 addresses with a truncated double-SHA256 checksum. They were part of...
350 - Bech32m format for v1+ witness addresses
BIP: 350 source Layer: Applications Title: Bech32m format for v1+ witness addresses Author: Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0350 Status: Final Type: Standards Track Created: 2020-12-16 License: BSD-2-Clause Replaces: 173 Post-History: 2021-01-05: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018338.html [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address Table of ContentsIntroductionAbstractCopyrightMotivationSpecificationBech32mAddresses for segregated witness outputsCompatibilityReference implementationsTest vectorsTest vectors for Bech32mTest vectors for v0-v16 native segregated witness addressesAppendix: checksum design & propertiesError patterns & detection probabilityDetection properties of Bech32mSelection processFootnotesAcknowledgements Introduction Abstract This document defines an improved variant of Bech32 called Bech32m, and am...
342 - Validation of Taproot Scripts
BIP: 342 source Layer: Consensus (soft fork) Title: Validation of Taproot Scripts Author: Pieter Wuille Jonas Nick Anthony Towns Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0342 Status: Final Type: Standards Track Created: 2020-01-19 License: BSD-3-Clause Requires: 340, 341 Post-History: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal Table of ContentsIntroductionAbstractCopyrightMotivationDesignSpecificationScript executionRules for signature opcodesCommon Signature Message ExtensionSignature validationResource limitsRationaleDeploymentExamplesAcknowledgements Introduction Abstract This document specifies the semantics of the initial scripting system under BIP341. Copyright This document is licensed under the 3-clause BSD license. Motivation BIP341 proposes improvements to just the script structure, but some of...
143 - Transaction Signature Verification for Version 0 Witness Program
BIP: 143 source Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0143 Status: Final Type: Standards Track Created: 2016-01-03 License: PD Table of ContentsAbstractMotivationSpecificationRestrictions on public key typeExampleNative P2WPKHP2SH-P2WPKHNative P2WSHP2SH-P2WSHNo FindAndDeleteDeploymentBackward compatibilityReference ImplementationReferencesCopyright Abstract This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. Motivation There are 4 ECDSA signature verification codes in the original Bitcoin script system: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sigha...
330 - Transaction announcements reconciliation
BIP: 330 source Layer: Peer Services Title: Transaction announcements reconciliation Author: Gleb Naumenko Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0330 Status: Draft Type: Standards Track Created: 2019-09-25 License: CC0-1.0 License-Code: MIT Table of ContentsAbstractMotivationErlaySpecificationNew data structures32-bit short transaction IDsShort transaction ID sketchesIntended Protocol FlowSketch extensionNew messagessendtxrcnclreqreconsketchreqsketchextreconcildiffLocal stateReconciliation saltReconciliation setsReconciliation set snapshotSketch capacity estimation and q-coefficientBackward compatibilityRationaleWhy use PinSketch for set reconciliation?Why use 32-bit short transaction IDs?Why use sketch extensions instead of bisection?ImplementationAcknowledgmentsCopyright Abstract This document specifies a P2P protocol extension for reconciliation of transaction announcements be...
141 - Segregated Witness (Consensus layer)
BIP: 141 source Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer) Author: Eric Lombrozo Johnson Lau Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0141 Status: Final Type: Standards Track Created: 2015-12-21 License: PD Table of ContentsAbstractMotivationSpecificationTransaction IDCommitment structureWitness programOther consensus critical limitsBlock sizeSigopsAdditional definitionsTransaction size calculationsNew script semanticsExamplesP2WPKHP2WPKH nested in BIP16 P2SHP2WSHP2WSH nested in BIP16 P2SHExtensible commitment structureTrust-free unconfirmed transaction dependency chainFuture extensionsCompact fraud proof for SPV nodesNew script systemPer-input lock-time and relative-lock-timeBackward compatibilityDeploymentCreditsFootnotesReference ImplementationReferencesCopyright Abstract This BIP defines a new structure called a "witness" that is committed ...
340 - Schnorr Signatures for secp256k1
BIP: 340 source Title: Schnorr Signatures for secp256k1 Author: Pieter Wuille Jonas Nick Tim Ruffing Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0340 Status: Final Type: Standards Track License: BSD-2-Clause Created: 2020-01-19 Post-History: 2018-07-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html [bitcoin-dev] Schnorr signatures BIP Table of ContentsIntroductionAbstractCopyrightMotivationDescriptionDesignSpecificationPublic Key GenerationPublic Key ConversionDefault SigningAlternative SigningVerificationBatch VerificationUsage ConsiderationsMessages of Arbitrary SizeDomain SeparationApplicationsMultisignatures and Threshold SignaturesAdaptor SignaturesBlind SignaturesTest Vectors and Reference CodeChangelogFootnotesAcknowledgements Introduction Abstract This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve secp256k1. Cop...
32 - Hierarchical Deterministic Wallets
RECENT CHANGES: (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage)(30 Apr 2013) Switched from multiplication by IL to addition of IL (faster, easier implementation)(25 May 2013) Added test vectors(15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions.(24 Feb 2017) Added test vectors for hardened derivation with leading zeros(4 Nov 2020) Added new test vectors for hardened derivation with leading zeros BIP: 32 source Layer: Applications Title: Hierarchical Deterministic Wallets Author: Pieter Wuille Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032 Status: Final Type: Informational Created: 2012-02-11 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecification: Key derivationConventionsExtended keysChild key derivation (CKD) functionsPrivate parent key → private child keyPublic parent key →...
341 - Taproot
BIP: 341 source Layer: Consensus (soft fork) Title: Taproot: SegWit version 1 spending rules Author: Pieter Wuille Jonas Nick Anthony Towns Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341 Status: Final Type: Standards Track Created: 2020-01-19 License: BSD-3-Clause Requires: 340 Post-History: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal 2019-10-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017378.html [bitcoin-dev] Taproot updates Table of ContentsIntroductionAbstractCopyrightMotivationDesignSpecificationScript validation rulesSignature validation rulesCommon signature messageTaproot key path spending signature validationConstructing and spending Taproot outputsSecurityTest vectorsRationaleDeploymentBackwards compatibilityAcknowledgements Introduction Abstract This do...
324 - Version 2 P2P Encrypted Transport Protocol
BIP: 324 source Layer: Peer Services Title: Version 2 P2P Encrypted Transport Protocol Author: Dhruv Mehta Tim Ruffing Jonas Schnelli Pieter Wuille Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0324 Status: Draft Type: Standards Track Created: 2019-03-08 License: BSD-3-Clause Replaces: 151 Table of ContentsIntroductionAbstractCopyrightMotivationGoalsSpecificationTransport layer specificationOverview and designHandshake: key exchange and version negotiationShared secret computationElligatorSwift encoding of curve X coordinatesKeys and session ID derivationOverall handshake pseudocodePacket encryptionExisting cryptographic primitivesRekeying wrappers: FSChaCha20Poly1305 and FSChaCha20Overall packet encryption and decryption pseudocodePerformanceApplication layer specificationv2 Bitcoin P2P message structureSignaling specificationSignaling v2 supportTest VectorsRationale and ReferencesAcknowledgements Introduction Abs...
147 - Dealing with dummy stack element malleability
BIP: 147 source Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Author: Johnson Lau Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147 Status: Final Type: Standards Track Created: 2016-09-02 License: PD Table of ContentsAbstractMotivationSpecificationDeploymentCompatibilityImplementationAcknowledgementsCopyright Abstract This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Motivation Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness (BIP141) ...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 source Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Rejected Type: Standards Track Created: 2015-08-24 Table of ContentsAbstractMotivationSpecificationProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersRationaleProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersCompatibilityOther solutions consideredDeployment Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Dependi...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Author: Eric Lombrozo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs Abstract This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. Copyright This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. Motivation Bitcoin is a system involving a number of different standards. Some standards are abso...
151 - Peer-to-Peer Communication Encryption
BIP: 151 source Layer: Peer Services Title: Peer-to-Peer Communication Encryption Author: Jonas Schnelli Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 Status: Replaced Type: Standards Track Created: 2016-03-23 License: PD Superseded-By: 324 Table of ContentsAbstractMotivationSpecificationSymmetric Encryption Cipher KeysSession IDThe encinit message typeChaCha20-Poly1305 Cipher SuiteThe encack message typeEncrypted Messages StructureRe-KeyingRisksCompatibilityReference implementationReferencesAcknowledgementsCopyright Abstract This BIP describes an alternative way that a peer can encrypt their communication between a selective subset of remote peers. Motivation The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostl...
322 - Generic Signed Message Format
BIP: 322 source Layer: Applications Title: Generic Signed Message Format Author: Karl-Johan Alm Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 Status: Draft Type: Standards Track Created: 2018-09-10 License: CC0-1.0 Table of ContentsAbstractMotivationTypes of SignaturesLegacySimpleFullFull (Proof of Funds)Detailed SpecificationVerificationVerification ProcessSigningCompatibilityReference implementationAcknowledgementsReferencesCopyrightTest vectorsMessage hashingMessage signingTransaction Hashes Abstract A standard for interoperable signed messages based on the Bitcoin Script format, either for proving fund availability, or committing to a message as the intended recipient of funds sent to the invoice address. Motivation The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures tha...
116 - MERKLEBRANCHVERIFY
BIP: 116 source Layer: Consensus (soft fork) Title: MERKLEBRANCHVERIFY Author: Mark Friedenbach Kalle Alm BtcDrak Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0116 Status: Draft Type: Standards Track Created: 2017-08-25 License: CC-BY-SA-4.0 License-Code: MIT Table of ContentsAbstractCopyrightSpecificationMotivationRationaleApplications1-of-N for large NHoneypotsImplementationDeploymentCompatibilityReferences Abstract A general approach to bitcoin contracts is to fully enumerate the possible spending conditions and then program verification of these conditions into a single script. At redemption, the spending condition used is explicitly selected, e.g. by pushing a value on the witness stack which cascades through a series if if/else constructs. This approach has significant downsides, such as requiring all program pathways to be visible in the scriptPubKey or redeem script, even those whic...